Detection of escalation paths in cloud environments

ABSTRACT

A method for detecting escalation paths in a cloud environment is provided. The method includes accessing a security graph representing cloud objects and their connections in the cloud environment; analyzing each cloud object to detect an escalation hop from a current cloud object to a next cloud object, wherein the analysis is based, in part, on a plurality of risk factors and reachability parameters determined for each cloud object; and marking the security graph with each identified escalation path in the security graph, wherein an escalation path is a collection of escalation hops from a source cloud object to a destination cloud object.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Non-Provisional applicationSer. No. 17/504,053, filed Oct. 18, 2021, the contents of which arehereby incorporated by reference.

TECHNICAL FIELD

The present disclosure relates generally to cybersecurity and, inparticular, to detection of escalation paths in the cloud environment.

BACKGROUND

As businesses, governments, and organizations increasingly implementdigital and connected technologies to efficiently manage operations,seamlessly connect with users, and otherwise improve offerings, the sametechnologies may create elevated security risks for the implementingparty. Seemingly separate digital technologies may be interconnectedwithin an organization's network, creating risks where vulnerability inone system could expose additional vulnerabilities in other, connectedsystems. As an example, a large retailer, operating many stores andprocessing large quantities of transactions, may rely on a paymentprocessing system to collect and organize credit card payments for goodssold in brick-and-mortar stores. While the payment processing systemused may be well-supported and resistant to cyberattacks, the system maybe interconnected with other, less secure systems, such as a store'snetwork. Where, in the same example, a store includes only a singledigital entrance and exit point, such as an internet connection providedby a single internet service provider (ISP), payment systems, heating,ventilation, and air-conditioning (HVAC) systems, in-store musicsystems, and the like, which may be interconnected by the systems'connections with the single internet access connection. Where, in thesame example, an attacker is able to gain malicious access to anin-store HVAC system, the attacker may use this access to move fromsystem to system within the store's network, eventually gaining accessto the retailer's global payment system, which includes the customers'credit card information. Further, in a similar example, an attacker maybe able to gain access to protected cloud accounts, such as anadministrator-role account for an online shopping platform, by gainingsimilar access to an unprotected, external system and, using access keysmade accessible by vulnerabilities included in the external system,maneuver through one or more systems of the network environment toultimately gain administrator access.

The technique described with respect to the above example is commonlyreferred to as “lateral movement” or “attack escalation”. Attackersemploying lateral movement techniques may seek to compromise anauxiliary system, which does not include sensitive data and, from thecompromised system, move laterally within a network to collect sensitivedata and compromise more secure systems. During the execution of suchattacks, attackers may survey network systems, collecting informationregarding connections within the network, security measures, and thelike, and, using this information, search less secure systems anddevices for credentials and other data, which may grant access to moresecure systems and devices. As the risk posed to a business or otherorganization by such attacks may be great, network administrators, andthe like, may employ various systems and techniques to identifyattackers, block access, and otherwise mitigate potential damage.However, due to the shortcomings of such solutions, many attacks may bedetected only after the attacker has secured access or compromisedvaluable data.

Various solutions may be employed to identify potential attack vectors,by which attackers may execute such movements, and restrict the accessof such attackers, such as by remedying vulnerabilities leading topotential escalation paths, and otherwise mitigate potential damage.Solutions may include device-level, system-level, and network-levelsystems and methods, where such solutions may be directed to variousaspects of detection and prevention. However, such solutions may belimited by various functional restrictions, including operationsrestricting detection and prevention to single network objects, singlenetwork sub-systems, or single layers of a network environment.

Organizations have transitioned to cloud environments which provideflexibility in the execution of applications or services, but at thesame time, increase overall network vulnerability due to the complexityof the cloud infrastructure. That is, a typical cloud environment mayinclude many cloud objects that participate in the execution of a singleprocess or service of an application. A cloud object is a physical orvirtual entity including those such as compute objects that may executeor are capable of executing code in the cloud, store or are capable ofstoring data in a cloud, provide or are capable of providing a networkconnection, and the like. Every cloud object has a set of configurationsand can communicate or share information with other nodes. Thus, thereare a number of vulnerable points which can be exploited by an attacker.For example, a misconfiguration of a device may allow access to thatwhich a second object holding sensitive information cannot grant.

As such, solutions which offer detection and prevention for single(isolated) devices, objects, and the like, may not be suitable toprotect an organization's cloud environment as a whole. Further,existing solutions cannot detect escalation paths from one cloud objectto another; such solutions may fail to provide for the management ofattack vectors resulting from access to various cloud objects. Further,existing solutions may alert on potential lateral movement by relying ondetecting a single vulnerability issue with each cloud object. However,such an issue, even if detected, cannot lead to attack escalation (orlateral movement). For example, the object can be scanned to identifyvulnerable operation system processes, and from that, derive privilegeescalation. However, the privilege escalation may be caused bymisconfiguration of network parameters, and thus cannot be detected.Therefore, existing security solutions fail to consider and analyze allsecurity aspects related to a cloud object, and therefore may fail toprovide for complete protection of an organization's networkinfrastructure against such attacks.

It would therefore be advantageous to provide a solution that wouldovercome the challenges noted above.

SUMMARY

A summary of several example embodiments of the disclosure follows. Thissummary is provided for the convenience of the reader to provide a basicunderstanding of such embodiments and does not wholly define the breadthof the disclosure. This summary is not an extensive overview of allcontemplated embodiments and is intended to neither identify key orcritical elements of all embodiments nor to delineate the scope of anyor all aspects. Its sole purpose is to present some concepts of one ormore embodiments in a simplified form as a prelude to the more detaileddescription that is presented later. For convenience, the terms “someembodiments” or “certain embodiments” may be used herein to refer to asingle embodiment or multiple embodiments of the disclosure.

Certain embodiments disclosed herein include a method for detectingescalation paths in a cloud environment. The method comprises accessinga security graph representing cloud objects and their connections in thecloud environment; analyzing each cloud object to detect an escalationhop from a current cloud object to a next cloud object, wherein theanalysis is based, in part, on a plurality of risk factors andreachability parameters determined for each cloud object; and markingthe security graph with each identified escalation path in the securitygraph, wherein an escalation path is a collection of escalation hopsfrom a source cloud object to a destination cloud object.

Certain embodiments disclosed herein also include a non-transitorycomputer-readable medium having stored thereon instructions for causinga processing circuitry to execute a process for detecting escalationpaths in a cloud environment, the process comprising accessing asecurity graph representing cloud objects and their connections in thecloud environment; analyzing each cloud object to detect an escalationhop from a current cloud object to a next cloud object, wherein theanalysis is based, in part, on a plurality of risk factors andreachability parameters determined for each cloud object; and markingthe security graph with each identified escalation path in the securitygraph, wherein an escalation path is a collection of escalation hopsfrom a source cloud object to a destination cloud object.

In addition, certain embodiments disclosed herein include a systemdetecting escalation paths in a cloud environment. The system comprises:a processing circuitry; and a memory, the memory containing instructionsthat, when executed by the processing circuitry, configure the systemto: access a security graph representing cloud objects and theirconnections in the cloud environment; analyze each cloud object todetect an escalation hop from a current cloud object to a next cloudobject, wherein the analysis is based, in part, on a plurality of riskfactors and reachability parameters determined for each cloud object;and mark the security graph with each identified escalation path in thesecurity graph, wherein an escalation path is a collection of escalationhops from a source cloud object to a destination cloud object.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter disclosed herein is particularly pointed out anddistinctly claimed in the claims at the conclusion of the specification.The foregoing and other objects, features, and advantages of thedisclosed embodiments will be apparent from the following detaileddescription taken in conjunction with the accompanying drawings.

FIG. 1 is a diagram of a cloud analysis architecture, utilized todescribe the various embodiments.

FIG. 2 is a diagram of a security graph utilized to describe the variousembodiments.

FIGS. 3A and 3B are flowcharts depicting a method for detectingescalation paths in a graph, according to an embodiment.

FIG. 4 is a diagram showing an example escalation path detected on asecurity graph.

FIG. 5 is a hardware block diagram depicting a cybersecurity system,according to an embodiment.

DETAILED DESCRIPTION

It is important to note that the embodiments disclosed herein are onlyexamples of the many advantageous uses of the innovative teachingsherein. In general, statements made in the specification of the presentapplication do not necessarily limit any of the various claimedembodiments. Moreover, some statements may apply to some inventivefeatures but not to others. In general, unless otherwise indicated,singular elements may be in plural and vice versa with no loss ofgenerality. In the drawings, like numerals refer to like parts throughseveral views.

Privilege escalation is the act of exploiting a bug, design flaw, orconfiguration oversight in an operating system or software applicationin order to gain elevated access to resources that are normallyprotected from an application or user. According to the disclosedembodiments, a method and system for detecting privilege escalationpaths in a cloud environment is disclosed. An escalation path is whenone cloud object (resource) is exploited to access at least anotherresource connected thereto with privilege access. The disclosedembodiments provide a comprehensive risk analysis of cloud objects in acloud environment to detect any risks that may lead to unauthorizedprivilege escalations. The analysis may include, but is not limited to,vulnerability, identity, network exposed secrets, and technologies.

In an embodiment, the analysis is performed on a security graph showingall cloud objects and their connections in the cloud environment. Thus,by performing risk analysis on cloud objects, escalation path originsfrom each risky object can be determined.

It should be noted that in the disclosed embodiments, escalation pathscannot be determined through a manual process due to the number ofobjects (thousands) in a typical cloud environment, the frequent changesin objects, frequent code changes, and so on. The detection of possibleescalation paths is a dynamic process.

FIG. 1 is an example diagram of a cloud environment 100 utilized todescribe the various embodiments. A cloud environment 100 represents anorganization's cloud-based resources, and the various connectionsbetween such resources. The cloud environment 100 may include multiplecloud objects 105-1 through 105-n (hereinafter, “objects” 105 or“object” 105), one or more applications 106 (collectively referred to asapplications or apps 106). Further, the cloud environment 100 may beconfigured to connect, via a network 108, with a cybersecurity system150 for one or more purposes including, and without limitation, thosedescribed hereinbelow.

A cloud environment 100 may be a commercially available cloud system,provided on a service basis, such as, as examples and withoutlimitation, Amazon AWS®, Microsoft Azure®, and the like. A cloudenvironment 100 may be a private cloud, a public cloud, a hybrid cloud,and the like. In addition, a cloud environment 100 may include, withoutlimitation, container orchestration or management systems or platformssuch as, as an example, a Kubernetes® deployment, and the like, as wellas any combination thereof.

Cloud objects 105 may include objects, systems, devices, components,applications, entities, and the like, configured to operate within thecloud environment 100, and provide various functionalities therein.Cloud objects 105 may include one or more types of objects, including,without limitation, network objects, compute objects, and the like. Acloud object 105 may be a physical entity, a virtual entity, or acombination thereof.

Network objects are objects 105 configured to provide one or moretraffic-management functionalities within a network. Examples of networkobjects include, without limitation, proxies, load balancers, firewalls,and the like. Further, compute objects are objects 105 configured toprovide one or more data processing or management functionalities.Examples of compute objects 105 include, without limitation, databases,fileservers, dedicated processing hardware, and the like. Examples forvirtual compute objects 105 include virtual machines, softwarecontainers, serverless functions, microservices, and the like.

Cloud objects 105 may be configured to include one or more communicationports, where the included communication ports provide for the connectionof various objects 105 according to one or more protocols, and atdifferent communication layers of the OSI model. In an exampleconfiguration, the objects 105 are virtual entities or instances ofsubnets, hubs, virtual private networks (VPNs), and the like, as well asany combination thereof.

The applications 106, as may be hosted, executed, and the like, as wellas any combination thereof, the cloud environment 100 include services,processes, and the like, configured to provide one or morefunctionalities by execution of various commands and instructions. Theapplications 106 may interact or communicate with other objects,applications, and other, like features, including those objects,applications, and the like, deployed in separate networks, cloudenvironments, and the like, as well as any combination thereof.

To the network 108, a cybersecurity system 150 and a graph database (DB)160 are connected. The system 150 and DB 160 may be physically separatedfrom the cloud environment 100 or may be co-located with the cloudenvironment 100. The cybersecurity system 150, is configured to identifyescalation paths in a security graph stored in the graph database 160.The security graph includes a collection of network and computinggraphs.

The network 108 may connect the cloud environment 100 with the graphdatabase DB and the system 150. The network 108 may be implemented as aphysical network of discrete systems, devices, components, objects, andthe like, as a virtual network, providing for the interconnection ofvarious virtual systems and devices, as well as a hybridphysical-virtual network, including both physical and virtualizedcomponents. The network may be, for example and without limitation, alocal area network, a wide area network, the Internet, the World-WideWeb (WWWV), and the like, as well as any combination thereof.

The cybersecurity system 150 is configured to provide one or morecybersecurity functionalities including, without limitation,identification of escalation paths, as will be discussed below. Thecybersecurity system 150 may be configured as a physical system, device,or component, as a virtual system, device, or component, or as a hybridphysical-virtual configuration. A detailed description of acybersecurity system, 150, according to an embodiment, is provided withrespect to FIG. 5 , below. The cybersecurity system 150 can determineescalation paths in the cloud environment 100 without having any device,agent, service, and the like installed in the environment 100 or thecloud objects 105.

It may be understood that, while the cybersecurity system 150 isdepicted in FIG. 1 as an element of a remote cloud environment (i.e.,not the cloud environment 100 being processed), the cybersecurity system150 may be included within any of the various elements of the networkarchitecture, including the cloud environment 100.

The graph database (graph DB) 160 is a storage or memory component,device, system, or the like, configured to provide one or morefunctionalities relevant to the storage of graph-related data. The graphDB 160 may be configured to store graph-related data features of one ormore types or formats, including, without limitation, raw data, graphs,graph edges, graph vertices, graph schemas, and the like, as well as anycombination thereof, including those types or formats describedhereinbelow.

The graph DB 160 may be configured as a physical entity, a virtualentity, and the like. It may be understood that, while the graph DB 160is depicted in FIG. 1 as an element of the remote environment, the graphDB 160 may be included within any of the various elements of the networkarchitecture, including the cloud environment 100, and subparts thereof,and the network 108, and the like, without loss of generality ordeparture from the scope of the disclosure. Further, it may beunderstood that the graph DB 160 may be directly connected to, orrealized as a component of, the graph analysis system 150, without lossof generality or departure from the scope of the disclosure.

Graphs, as may be included in the graph DB 160, are data featuresincluding one or more graph vertices, where such graph vertices may bevariously interconnected by one or more graph edges. Graphs may beconfigured to provide for one or more representations of various datasets, including, without limitation, the presentation of network dataaccording to one or more graph schemas, as described hereinbelow. As anexample, a graph relevant to the description of a collection ofinterconnected objects may include one or more graph vertices, whereeach graph vertex corresponds to an object, and graph edges between suchvertices, where the edges correspond with the connections between thevarious objects.

In an embodiment, the graph DB 160 may be configured to store at leastone security graph generated to include cloud objects 105 included inthe cloud environment 100. The security graph configured to includelabeling functionality may be further configured to provide for thelabeling of graph vertices, graph edges, or both, with one or morelabels describing the various properties of a cloud object 105. In anembodiment, one of the properties may include a risk factor, determinedby risk analysis of the cloud object 105. A risk factor may bedetermined based, in part, on vulnerability analysis, identity analysis,network exposed secrets analysis, technologies analysis, and the like,or any combination thereof.

FIG. 2 is an example security graph 200 describing the disclosedembodiments for identifying privilege escalation paths in a cloudenvironment according to an embodiment. The example security graph 200may include a plurality of cloud objects, here 6 cloud objects 210-1through 210-6. Examples of types of cloud objects are discussed above.

Cloud objects 210 may be connected to each other, for example, an object210-1 is connected to objects 210-2 and 210-3. A connection (representedby vertex 220) may be a network connection, an access role, an API, andso on. For example, the object 210-1 is a virtual VM and the objects210-2 and 210-3 are access roles.

Cloud objects are connected in the graphs via vertices (collectivelylabeled as ‘220’) that may represent connections between the variousobjects. Such connections may represent data, control, networkconnections, and/or other types of relationships.

Each cloud object 210 is represented with an enriched data set (EDS)that is saved as part of the graph. An EDS may include an object name,an object type, an object connection latency, risk factors, reachabilityparameters, technology type, and object properties.

Object properties may include secrets, identities, and other provisions,information, and the like. Identities define object access roles orprofiles. Examples of object access roles or profiles may include “useraccess”, “guest access”, “power user access” roles, “administratoraccess”, and the like. The roles may be defined with access permission,such as, but not limited to, limited access, read-only, full access, andthe like. Secrets are related to access credentials and may include, asexamples and without limitation, usernames, passwords, access topersonal identification numbers (PINs), timed access tokens, and thelike, and so on.

The reachability parameters may include a source IP address, adestination IP address, a port number, a security group, and so on. Thereachability parameters are used to determine how one object can bereached or can access another object through one or more hops. Forexample, an object 210-4 (gateway) is currently active, and is connectedto an object 210-5 (VM) via the port 8080, using the HTTP protocol.Example techniques for detecting reachability parameters andreachability of cloud objects are further discussed in U.S. patentapplication Ser. No. 17/179,135, assigned to the common assignee and itis hereby incorporated by reference for all that it contains.

The risk factors are generated by performing risk analysis on each cloudobject 220. A risk factor can be represented using a score, description,or combination thereof. According to the disclosed embodiments, the riskanalysis may include vulnerability analysis to detect any known orunknown vulnerabilities identified in the object.

The risk analysis may further include identity analysis to detect anymisconfiguration or other issues of an identity in an object. Anidentity is an example of a principal, which acts on a cloud object(resource) 210. An identity may be, for example, a username, of aperson, an organization, and so on. An identity vulnerability may occurwhen the identity is used to access another similar object (e.g., user Ais able to access emails of user B). Another example of identityvulnerability may include using the identity of an object to accesspermission of another object. Another example of identity vulnerabilityis when an identity of a first object is associated with a permission toact on a second object. The various techniques for detecting identityvulnerabilities are discussed, for example, in US Patent ProvisionalApplication Nos. 63/222,709, 63/222,714, and 63/222,719, assigned to thecommon assignee and they are hereby incorporated by reference.

According to the disclosed embodiments, the risk analysis may includeexposed secrets analysis to detect exposed or weak secrets. Secrets mayinclude login credentials (e.g., passwords) that were either guessed,stored locally in the object, or were previously compromised. An exampletechnique for secret analysis can be found in U.S. ProvisionalApplication No. 63/212,975, assigned to the common assignee and it ishereby incorporated by reference.

According to the disclosed embodiments, the risk analysis may includevulnerability analysis related to a technology product implemented by acloud object. A technology product may include a software product, asoftware service, a hardware product, an infrastructure service, aninfrastructure product, and the like. For example, MongoDB® is a type oftechnology for implementing a database object. As another example, avirtual machine can be realized as an Apache® web server (technologyproduct). The risk analysis of technology products may includevulnerabilities known to be relevant to the specified technology, anyversion of the technology, and so on. For example, Apache® web serverversion ‘v02’ has a known vulnerability that should be addressed.Techniques for detecting vulnerabilities of technologies are furtherdiscussed in U.S. patent application Ser. No. 17/190,148, assigned tothe common assignee and it is hereby incorporated by reference for allthat it contains.

In an embodiment, the risk analysis may relate to network objects, i.e.,cloud objects classified as network devices (virtual or physical). Thenetwork analysis may include determining if a cloud (network) object isaccessible from an external network (e.g., the Internet) and/or ifaccess to such an object is secured. The network analysis may be basedon the reachability parameters as discussed in the above-referenced Ser.No. 17/179,135 application.

According to the disclosed embodiments, potential escalation paths ofprivilege escalations are detected by traversing the security graph 200.An escalation path is when privilege escalation in one object allowsaccess to another object connected thereto. That is, an escalation pathis a combination of privilege escalations from a source object to adestination object in the security graph 200. The destination may alsobe a combination of a cloud object and role (e.g., VM withIAM:attachRolePolicy can escalate to any role). An escalation path isdetermined when there is access to an object hosting sensitive data orresources.

As will be discussed below, a potential privilege escalation isdetermined by analyzing the EDSs associated with each cloud object inthe graph to determine if privilege escalations can be achieved toaccess another node, connected thereto. The detection of a potentialpath is further performed by analyzing reachability parameters,identity, secrets, and risk factors (vulnerabilities) of eachencountered object. The analysis can start at a source object and end ata destination object, by traversing the graph, searching the graph, andso on.

It should be emphasized that escalation paths may include a sequence ofcloud objects 210 (two or more) of different types. That is, escalationpaths detected according to the same embodiments may include acollection of compute objects (e.g., VMs), network objects (e.g., NICs),cloud platforms (different IaaSs), and applications. A path may includeobjects of the same type.

The detected escalation paths can be marked on the security graph 200 orsaved in a separate database (not shown). The security graph 200 can bequeried on any detected escalation paths. In an embodiment, any securitygraph 200 can be reported to a user.

FIG. 3A is an example flowchart 300 depicting a method for identifyingescalation paths in a cloud environment according to an embodiment.

At S310, a security graph stored in a graph database is accessed. Asdescribed hereinabove, a security graph lists all cloud objects andtheir connections in the cloud environment. Further, each node(representing an object) in the security graph lists the EDSs for theobject. An EDS may include object properties, readability parameters,risk factors, and so on. Detailed descriptions of the EDSs are discussedin greater detail above. In an embodiment, the graph may designate aseed (or source) node.

At S320, the accessed security graph is analyzed to identify potentialescalation paths. An escalation path is when privilege escalation in oneobject allows to access another object connected thereto, where aconnection may be data, network, or control connection. That is, anescalation path is a combination of privilege escalations from a sourceobject to a destination object in the security graph. In an embodiment,an escalation path is determined when there is access to an objecthosting sensitive data or resources.

In an embodiment, S320 includes traversing the security graph andanalyzing each encounter node (object) in the graph to determine if anyrisk factors can be exploited to reach another cloud object. It isfurther determined if a reached object in the path holds, contains, orprovides access to sensitive information that can harm the organization.This would allow for the ranking of detected escalation paths accordingto the severity of the exposed data. The analysis of cloud objects mayinclude analyzing EDS associated with each object in the security graph.In an example embodiment, the analysis can start at a designated sourcesecurity object, and end at a destination object.

The operation of S320 is illustrated in FIG. 3B. At S321, a sourceobject or node in the security graph is selected. The source node is thefirst cloud object to start the graph traversal. The source node may bedesignated in the graph, preselected by a user, or randomly selected.The source node may also include the next hop in a detected escalationhop. It should be noted that in certain embodiments, the first cloudobject (node) is a destination object to determine if there are anyescalation paths that can reach such a cloud object.

At S322, an EDS of the cloud object is accessed and analyzed todetermine if there is an escalation hop from the current object to anobject connected thereto, for example, an escalation hop from an object220-1 to an object 220-2. In an embodiment, the analysis is performed byprocessing all risk factors in the EDS, reachability parameters,secrets, and identities, thus providing a multi-layer analysis ofpotential privilege escalation. The analysis is static analysis, i.e.,static simulation of the potential escalation hop from one object toanother. The static analysis may include analysis of information of inthe EDS, based on simulated reachability, as defined in the respectiveEDS. It should be noted that simulated analysis does not include sendingany traffic, control, or actually attempting to exploit the detectedvulnerability. As an example, if a first object is a proxy device thatsaves (e.g., in a log file) a secret (password) to access a repositoryand the reachability parameter indicates that the proxy device isconnected to the repository through an open port, that would indicate apotential escalation hop.

Generally, the static simulation attempts to determine if a combinationof a risk factor and at least one reachability parameter leads toescalation to a different cloud object, including different roles.

The simulation can attempt specific escalation for roles, secrets, andvulnerabilities. For a role escalation, it is checked if a combinationof permission conditions and resource conditions lead to escalation to aspecific role(s). For example, lambda:updateFunctionCode and lambdafunctions in the account allow escalation to all roles currentlyassigned to lambda functions.

For secrets escalation, it is checked if there is a secret noted in therisk factor (stored in the object's EDS) providing access to a differentobject (e.g., disk, cloud key, VM, and the like). A chain of secrets canbe simulated. For example, [access to disk/storage]-->[cloudkey]-->[role] or [storage]-->[ssh key]-->[VM]

For vulnerability check, it is determined a cloud object is found tohave a validated (known) vulnerability and a reachability parameter to adifferent cloud object. For example, a compute object with a configurednetwork access validated vulnerability provides access to a VM.

Following are additional examples of potential escalation paths that canbe detected by the static analysis: a cloud object configured with“iam:*” permission; a cloud object configured with a cluster admin role;a cloud object configured with a cloud access key on its disk; and acloud machine configured with modification permissions “ec2.*”. In anembodiment, the analysis performed at S310 can detect escalation pathsthat can leverage multiple hops across identity and network access. Asan example, the attacker can leverage a serverless function in theproduction network (e.g., access a DB in production using a lambdafunction) permissions. The serverless function is exploited within theproduction network to launch and exploit against a critical service.

In an embodiment, the analysis can further detect escalation pathsacross different cloud platforms. For example, detection of an exposedcritical cloud key (secret) in a VM in one cloud platform (e.g., AWS®),wherein the key provides a login to a different cloud platform (e.g.,Azure®). The exposed key can further provide access to an account in the“target” cloud platform, thus leveraging the secret to continue theattack cross-cloud.

At S323, it is checked if there is an escalation hop, and if so,execution returns to S321 where a cloud object representing the next hopis selected and then analyzed. Otherwise, execution continues with S330.

It should therefore be appreciated that the analysis performed at S320can be utilized to detect potential escalation paths across multiplehops, domains, and cloud platforms.

At S330, any escalation path detected or identified at S320 is recorded.Escalation paths may be recorded by creating or updating one or moredata features to include descriptions of the escalation paths identifiedat S310. This may include marking nodes (cloud objects) that are part ofescalation paths, listing all paths and their objects, and updating anobject's EDS to note that such an object is part of an escalation path.

At S340, optionally, each recorded escalation path is ranked based onseverity. The ranking may be based on the type of objects in the pathbeing exposited, the type of data that can be accessed, how objects in adetected path can be reached (e.g., for external network or internalnetwork), who can access objects in a detected path (e.g., any publicaccess on organization access), the type of destination object of a path(i.e., if it is a designated object or a “sensitive” object), and so on.Such parameters can be weighted to compute a severity score for eachdetected escalation path. In an embodiment, the rank is determined basedon the probability that a detected escalation path indeed causesprivilege escalation. To this end, the escalation paths detection may beoperated in two different modes: deterministic (where the probability ofdetection is high) and undeterministic (where the probability ofdetection is low).

At S350, it is checked if the entire security graph was traversed oranalyzed. If so, execution continues with S360; otherwise, executionreturns to S312 where a new source node is selected.

At S360, detected escalation paths are reported. S360 may include thegeneration of one or more reports, presentations, displays, and thelike, such as may be relevant to report the described information. Itshould be noted that escalation paths can be obtained by querying thesecurity graphs, once the detected paths are marked thereto.

The method described herein may be performed by the system 150 (FIG. 1 )by accessing cloud objects and infrastructure. The analysis of suchobjects and infrastructures does not require the installation of anydedicated software agent or code in the cloud environment.

It should be noted that detecting escalation paths through traversingthe security graph is one example of implementation. Otherimplementations may include searching the graph, analyzing differentsections of the graph in parallel, and so on.

It should be further noted that nodes and cloud objects mayinterchangeably be discussed herein but refer to the same instance. Anode is a representation of a cloud object in the security graph.

FIG. 4 is an example diagram of a security graph 400 includingescalation paths, utilized to describe the various embodiments. Thedepicted example security graph 400 includes the following cloudobjects: a serverless function 410, VMs 420-1 through 420-3, DBs 430-1and 430-2, and a software container 440, which are variouslyinterconnected as depicted in the example diagram 400. It should benoted that the connections are not necessarily physical connections butmay represent a flow of data and/or control.

The security graph 400 provides an illustration of an escalation pathdetermination, as is discussed hereinbelow, for a path originating atthe serverless function 410 and directed to a DB 430-2. According to theexample, the serverless function 410 includes secrets relevant togaining access to VM 420-2, but not to gaining full privileges to VM420-2, and does not include secrets relevant to gaining access to VM420-1, and VM 420-2 includes secrets relevant to gaining full privilegesto DB 430-2, but not to the connected container 440 or DB 430-1.

During escalation path analysis, exposed secrets designed in EDS fromthe serverless function 420-1 are analyzed. In the example, an exposedsecret is a private encryption key that provides access from theserverless function 420-1 to VM 420-2. There is no exposed secret toaccess VM 420-1. In addition, path analysis, from the serverlessfunction 410, may include comparing the secrets collected from theserverless function 410 with the identities of each connected object.Thus, there is an escalation hop from a function 420-1 to a VM 420-2,and no escalation hop from function 420-1 to a VM 420-1.

Following the escalation hop from the function 410 to the VM 420-1, in aregular user role, the described escalation path analysis may continue,executed with respect to VM 420-2. As described, the VM 420-2 mayinclude a secret, private key, relevant to access DB 430-2 with fullprivileges, and no secrets relevant to DB 430-1 or the container 440.Thus, there is an escalation hop from VM 420-2 to DB 430-2. As fullprivileges are available for DB 430-2, based on the secrets collectedfrom the VM 420-2, execution may, according to the methods describedherein, terminate following identification of the last escalation hop.In this example, the escalation path would be the serverless function410 to the DB 430-2, via the VM 420-2.

In some embodiments, it is checked if information learned through theexploitation of one object would allow for a privilege escalation in acloud object not directly connected to the exploited cloud object. Forexample, it may be determined that a weak secret saved in VM 420-1 canbe used to access the DB 420-3.

The disclosed embodiments have been discussed herein with a reference toa specific embodiment where a cloud environment is analyzed. Theteachings discussed herein can be utilized to analyze escalation pathsin an infrastructure as a code (IaC) environment. Such environmentsprovide the blueprints for the deployment and execution of cloud objectsin a cloud embodiment.

FIG. 5 is an example hardware block diagram 500 depicting acybersecurity system 150, according to an embodiment. The cybersecuritysystem 150 includes a processing circuitry 510 coupled to a memory 520,a storage 530, and a network interface 540. In an embodiment, thecomponents of the cybersecurity system 150 may be communicativelyconnected via a bus 550.

The processing circuitry 510 may be realized as one or more hardwarelogic components and circuits. For example, and without limitation,illustrative types of hardware logic components that can be used includefield programmable gate arrays (FPGAs), application-specific integratedcircuits (ASICs), application-specific standard products (ASSPs),system-on-a-chip systems (SOCs), graphics processing units (GPUs),tensor processing units (TPUs), general-purpose microprocessors,microcontrollers, digital signal processors (DSPs), and the like, or anyother hardware logic components that can perform calculations or othermanipulations of information.

The memory 520 may be volatile (e.g., random access memory, etc.),non-volatile (e.g., read-only memory, flash memory, etc.), or acombination thereof.

In one configuration, the software for implementing one or moreembodiments disclosed herein may be stored in the storage 530. Inanother configuration, the memory 520 is configured to store such asoftware. Software shall be construed broadly to mean any type ofinstructions, whether referred to as software, firmware, middleware,microcode, hardware description language, or otherwise. Instructions mayinclude code (e.g., in source code format, binary code format,executable code format, or any other suitable format of code). Theinstructions, when executed by the processing circuitry 510, cause theprocessing circuitry 510 to perform the various processes describedherein.

The storage 530 may be magnetic storage, optical storage, and the like,and may be realized, for example, as flash memory or another memorytechnology, compact disk-read only memory (CD-ROM), Digital VersatileDisks (DVDs), or any other medium which can be used to store the desiredinformation.

The network interface 540 allows the cybersecurity system 150 tocommunicate with the various components, devices, and systems describedherein for escalation path detection, as well as other, like, purposes.

It should be understood that the embodiments described herein are notlimited to the specific architecture illustrated in FIG. 5 , and otherarchitectures may be equally used without departing from the scope ofthe disclosed embodiments.

It should be noted that computer-readable instructions may be construedbroadly to mean any type of instructions, whether referred to assoftware, firmware, middleware, microcode, hardware descriptionlanguage, or otherwise. Instructions may include code, such as in sourcecode format, binary code format, executable code format, or any othersuitable format of code. The instructions, when executed by thecircuitry, cause the circuitry to perform the various processesdescribed herein.

The various embodiments disclosed herein can be implemented as hardware,firmware, software, or any combination thereof. Moreover, the softwareis preferably implemented as an application program tangibly embodied ona program storage unit or computer-readable medium consisting of parts,or of certain devices and/or a combination of devices. The applicationprogram may be uploaded to, and executed by, a machine comprising anysuitable architecture. Preferably, the machine is implemented on acomputer platform having hardware such as one or more central processingunits (CPUs), a memory, and input/output interfaces. The computerplatform may also include an operating system and a microinstructioncode. The various processes and functions described herein may be eitherpart of the microinstruction code or part of the application program, orany combination thereof, which may be executed by a CPU, whether or notsuch a computer or processor is explicitly shown. In addition, variousother peripheral units may be connected to the computer platform, suchas an additional data storage unit and a printing unit. Furthermore, anon-transitory computer-readable medium is any computer-readable mediumexcept for a transitory propagating signal.

As used herein, the phrase “at least one of” followed by a listing ofitems means that any of the listed items can be utilized individually,or any combination of two or more of the listed items can be utilized.For example, if a system is described as including “at least one of A,B, and C,” the system can include A alone; B alone; C alone; A and B incombination; B and C in combination; A and C in combination; or A, B,and C in combination.

All examples and conditional language recited herein are intended forpedagogical purposes to aid the reader in understanding the principlesof the disclosed embodiment and the concepts contributed by the inventorto furthering the art, and are to be construed as being withoutlimitation to such specifically recited examples and conditions.Moreover, all statements herein reciting principles, aspects, andembodiments of the disclosed embodiments, as well as specific examplesthereof, are intended to encompass both structural and functionalequivalents thereof. Additionally, it is intended that such equivalentsinclude both currently known equivalents as well as equivalentsdeveloped in the future, i.e., any elements developed that perform thesame function, regardless of structure.

What is claimed is:
 1. A method for detecting escalation paths in acloud environment, comprising: determining that a first object deployedin a cloud computing environment is exposed to an external network;detecting a vulnerability on the first object; and detecting a potentiallateral movement path to a second object, based on the exposure and thevulnerability.
 2. The method of claim 1, further comprising: detecting apermission associated with the first object; and detecting the potentiallateral movement path further based on the detected permission.
 3. Themethod of claim 1, wherein the vulnerability is a known exploit.
 4. Themethod of claim 1, wherein the vulnerability is associated with asoftware version.
 5. The method of claim 1, further comprising:detecting sensitive data accessible by any one of: the first object, thesecond object, and a combination thereof.
 6. The method of claim 1,wherein the vulnerability is a wildcard permission.
 7. The method ofclaim 1, wherein the vulnerability is a cloud object configured with acluster admin role.
 8. The method of claim 1, wherein the vulnerabilityis a cloud access key on a disk of the first object.
 9. The method ofclaim 1, wherein the second object is deployed in a second cloudcomputing environment.
 10. The method of claim 9, wherein the secondcloud computing environment is deployed on a second cloud computinginfrastructure and the cloud computing environment is deployed on afirst cloud computing infrastructure.
 11. A non-transitorycomputer-readable medium storing a set of instructions for detectingescalation paths in a cloud environment, the set of instructionscomprising: one or more instructions that, when executed by one or moreprocessors of a device, cause the device to: determine that a firstobject deployed in a cloud computing environment is exposed to anexternal network; detect a vulnerability on the first object; and detecta potential lateral movement path to a second object, based on theexposure and the vulnerability.
 12. A system for detecting escalationpaths in a cloud environment comprising: a processing circuitry; and amemory, the memory containing instructions that, when executed by theprocessing circuitry, configure the system to: determine that a firstobject deployed in a cloud computing environment is exposed to anexternal network; detect a vulnerability on the first object; and detecta potential lateral movement path to a second object, based on theexposure and the vulnerability.
 13. The system of claim 12, wherein thememory contains further instructions which when executed by theprocessing circuitry further configure the system to: detect apermission associated with the first object; and detect the potentiallateral movement path further based on the detected permission.
 14. Thesystem of claim 12, wherein the vulnerability is a known exploit. 15.The system of claim 12, wherein the vulnerability is associated with asoftware version.
 16. The system of claim 12, wherein the memorycontains further instructions which when executed by the processingcircuitry further configure the system to: detect sensitive dataaccessible by any one of: the first object, the second object, and acombination thereof.
 17. The system of claim 12, wherein thevulnerability is a wildcard permission.
 18. The system of claim 12,wherein the vulnerability is a cloud object configured with a clusteradmin role.
 19. The system of claim 12, wherein the vulnerability is acloud access key on a disk of the first object.
 20. The system of claim12, wherein the second object is deployed in a second cloud computingenvironment.
 21. The system of claim 20, wherein the second cloudcomputing environment is deployed on a second cloud computinginfrastructure and the cloud computing environment is deployed on afirst cloud computing infrastructure.